’ LEY KNOX LIBRARY 

f.AYAL POSTGRADUATE SCHOOL 
t'ONTEREY, CALIF. 93940 



NAVAL 



POSTGRADUATE SCHOOL 

Monterey, California 




THESIS 



Implementation of the VGM Graphics System 
on the PDP-11/50 Under the RSX-11M Operating 
System and Construction of a Compatible 
Software Driver for the Ramtek RM-9400 

by 

Patrick Michael Comi 
June, 1982 



Thesis Advisor: G. A. Rahe 



Approved for public release, distribution unlimited 



T lO^SSl 




SECURITY classification OF This Mgi fWhm I Dme Entered) 



f REPORT DOCUMENTATION PAGE 


READ INSTRUCTIONS 
BEFORE COMPLETING FORM 


I r. RE font numiir 


2. GOVT ACCESSION NO. 


A- recipient's catalog number 


j 4. TITLE (end Subtltim) 

Implementation of the VGM Graphics System 
on the PDP-11/50 Under the RSX-11M Operat- 
ing System and Construction of a Compatibl 
I Software Driver for the Ramtex RM-9400 


s. tyre of report a perioo covered 

Master's Thesis 
June, 1982 


"6. performing org. report Number 


17. AuThODi'm 

I Patrick Michael Comi 


S. CONTRACT OR GRANT NUMBER^*; 


I*. PERFORMING ORGANIZATION NAMC AMO ADDRESS 

1 Naval Postgraduate School 
1 Monterey, California 93940 


T2SSV2« £ - u J EMeM , T ""ojcct. t*sk 

A **A 4 WORK UNIT NUMBERS 


III CONTROLLING OFFICE NAME ANO ADDRESS 

I Naval Postgraduate School 
I Monterey, California 93940 


12. REPORT OATE 

June, 1982 


1) number of page's 

87 


| 14. MONITORING agency name 6 ADORESS<l# different from Controlling Otttc*) 


l». SECURITY CLASS, (at ihl. r*>art) 

UNCLASSIFIED 


1S«. OeCL ASSIFICATION/ DOWNGRADING 

schedule 


[16. DISTRIBUTION STATEMENT (of thle Report) ~ — - — 

Approved for public release, distribution unlimited 


| 17. DISTRIBUTION STATEMENT (of the mb street entered In Slock 20, It different from Report) 


I 18. SUPPLEMENTARY NOTES 


| 19. KEY WORDS ( Continue m reverse elde It nece emery «4 Identify by kloek number) 

Computer graphics, CORE graphics system, graphics standardization, 
1 graphics program portability, Virtual Graphics Machine 


1 20. ABSTRACT (Continue on rovereo ml do it noeoeemy and Identity by block number) 

In 1977 the ACM Special Interest Group for Graphics (SIGGRAPH) 
formed the Graphics Standards Planning Committee (GSPC) to develop 
I a standard for the industry. The result of their efforts was the 
CORE graphics system. This study discusses that system and the 
I issues involved in its creation. It describes Bell Northern Re- 
1 search's approach to implementing CORE with their Virtual Graphics 

I T^e^ins taY^alion of VGM at the Naval Postgraduate School on a PDP 
I 11/50 with the RSX-11M operating system is described as well as the 
1 initial efforts to exnand it to drive* the Ramtex RM- 9 400 Granhics__ 



DD , 1473 COITION OF I NOV •• IS OBSOLETE 

S/N o 102-014- 6601 | 



1 



SECURITY CLASSIFICATION Of THIS PAOI (9kon Dote Sn torod) 



APPROVED FOR PUBLIC RELEASE, DISTRIBUTION UNLIMITED 



Implementation of tne VGM Grapnics System on tne PDP 
Under tne RSX-11M Operating System and Construction 
Compatible Software Driver for tne Ramtei RM-9400 



by 



Patrick M. Comi 

Lieutenant, United States Navy 
B.S., Union College, 1970 



Submitted in partial 
requirements for 



fulfillment of tne 
tne degree of 



MASTER OP SCIENCE IN COMPUTER SCIENCE 



from the 



11/50 
of a 



NA?AL POSTGRADUATE SCHOOL 
June 1982 



'f'U-i-oo 
C > 5 : 1 5 

c 



rkvtF n£? :OX libr ARY 

'C^ E R°y T ^n? UATESCH °OL 

* J 1 *-hL.Y, CALIF. 93240 



ABSTRACT 



In 1977 the ACM Special Interest Group for Graphics 
(SIGGRAPH) formed the Graphics Standards Planning Committee 
(GSPC) to develop a standard for the industry. The result of 
their efforts was the CORE graphics system. This study 
discusses that system and the issues involved in its 
creation. It describes Bell Northern Research's approacn to 
implementing CORE with their Virtual Graphics Machine (VGM). 

The installation of 7GM at the Naval Postgraduate 
School on a PDP 11/50 with the RSX-11M operating system is 
described as well as the initial efforts to expand it to 
drive the Ramtefc RM-9400 Graphics Display System. 
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I. INTRODUCTION 



Computer graphics is a relatively young tecnnology and 
is expanding at an extremely rapid rate. As a recognized 
discipline, it marts its birtn with Ivan E. Sutherland's 
SKETCHPAD , in 1962. As tne field has expanded, hardware has 
developed along several different lines. The available 
devices range from computer driven mechanical pen and int 
and photographic film plotters, to refresh display devices 
where digital stored images are repeatedly painted on a 
television-lite Cathode Ray Tube (CRT). There are also 
storage tube displays where the CRT itself retains the 
image, thereby eliminating the need for storage and 

continuous refreshing. The latest development has been the 
raster-scan devices where a matrix of intensity values is 
output to a refresh type CRT. 

The software supporting these various devices has 
developed along lines as diverse as the hardware. Despite 
wide variation in device capabilities there is a large body 
of graphics methodology that is common to all display 
systems. The existence of this body of shared technology 
has contributed significantly to the movement toward the 
development of a software system that would be common 
throughout the community of graphics programmers. 
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The concept of a standardized graphics system is not a 
new one. The publication of the ACM-SIGGRAPH Graphics 
Standards Planning Committee (GSPC) report in 1977, however, 
was the first widely accepted effort in the area of 
standardization. This CORE graphics system is, as yet, only 
a proposal. CORE is envisioned by the GSPC to be a first 
step toward a true, industry-wide standard. The nope for the 
current CORE system is that it will be implemented at a 
large number of computer graphics installations and be 
subjected to a variety of applications. Such widespread use 
of CORE is the best way to fully challenge the proposed 
standard. Sitensive use of the system will build a 
comprehensive body of knowledge about it and should 
nignlight its strengths and weaknesses. Based on such 
experience the system can be revised and restructured as 
necessary until ultimately it is accepted as a viable 
industry-wide standard. 

This project is intended to be an initial step toward a 
thorough study of the CORE grapnics system at the Naval 
Postgraduate School. The long term goal of the research is 
to implement the GSPC proposed system on tne graphics 
facility at the Naval Postgraduate School and critically 
examine its performance. 

When this research was begun, exposure to CORE at the 
Naval Postgraduate Scnool was limited to tne information 
available in the literature. No version of it was 
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operational at the facility. It was expected that the 
progress of tne wort would be slow wnile experience witn 
CORE was being accumulated. Since this study was the initial 
step, the emphasis was placed on producing a good foundation 
for wort that would follow. 

Naturally, the first step in the study of CORE was to 
implement a version of it. Tne PDP-11/50 computer and RSX- 
11 M operating system were the target environment for this 
phase. The CORE software was Bell Northern Research's 
Virtual G r aphics Ma chin e (V GM) . which was donated by that 
company to the Naval Postgraduate School for research 
purposes. A detailed report on the system installation is 
presented in Appendix A. 

An intermediate goal of the project is to extend the 
newly installed CORE system to a variety of devices. Toward 
this end the initial steps were tairen to incorporate an 
interface with the Ramtett RM-9400 graphics display system 
into the CORE software. Appendix B describes this portion of 
the research. 



As part 


of 


building 


a 


knowledge 


base 


for later 


research, tne CORE system 


and 


its development 


are discussed 


in detail. 


The 


discussion 


is 


Intended to 


give 


enough of an 


overview of 


tne 


system so 


that 


tne reader 


will 


not need to 



refer to the source documents except for essential details. 
An examination of the relationship between ?GM 
implementation and the CORE specification is also provided. 
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II. HISTORY 



A. THE PROBLEM Of NON-ST ANDARDIZED GRAPHICS SYSTEMS 

CJntil the mid 1970's individual graphics devices were 
operated with their own specialized software systems and 
their instruction sets were tailored to their own particular 
capabilities. Programming techniques generally were 
constrained by the device characteristics. Even program 
structure could be dictated by the available graphics 
system. Added to these restrictions would be additional 
requirements associated with installation computing hardware 
and operating systems. Such highly individualized equipment 
meant that each graphics system required specialized 
programs, and, in general, these were applicable for that 
installation and no other. 

As the field of computer grapnics expanded, such 
limitations became a real liability. The inability to use 
one program at more than one installation meant that for a 
given application a new set of software would have to be 
developed individually for each combination of hardware and 
operating system. The issue of non-portability eventually 
became an overriding concern of the industry. 

If the programs for particular devices were 
individualized then so was the training of the programmers. 
Every device required users to have fairly extensive 
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Knowledge of its operation. Rather than concentrate on 
graphics in a broad spectrum, application programmers sot 
involved in very low level, highly detailed programming for 
a specific device. This meant that much of the Knowledge and 
techniques developed by a programmer might be unuseable if 
the device were changed. Thus, a hardware change brought 
with it the necessity for an in-depth training program on 
tne new device. Furtner, the programmer would now nave to 
Keep the operating details of each device separate in his 
mind. Confusion of such details is hignly conducive to the 
introduction of additional bugs into programs. 

The prospect of worKing in a very restricted environment 
and of being required to assimilate and differentiate a host 
of idiosynchrasies , mnemonics, formats and operational 
details no doubt caused many potential graphics application 
programmers to turn to other fields of specialization. The 
graphics industry must count this to its detriment. 

Another problem, perhaps not quite as visible as the 
portability issues, but certainly as worthy of concern, was 
the difficulty researchers in graphics had in building on 
one another's worK. An application written, for example, for 
a storage tube display, would have to be completely 
rewritten for a raster device. The changes would be so 
numerous that equivalence of tne programs would be 
impossible to assert. Also, the full duplication of a piece 
of worK simply to adapt it to a different environment was a 
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costly process in terms of time and resources, botn human 
and machine. 



B. FORMATION OF THE GSPC 

In more recent years, tnere nave been some attempts to 
remove tne user from the details of device operation by 
providing high level software. This typically tooic the form 
of a package of subroutines callable from some standard nigh 
level language. Such packages did remove the need for 
programmer Knowledge of some of the device operating details 
(though by no means all of them) but each package was still 
unique. Thus, though a step forward had been made, programs 
written from different grapnics packages were still not 
portable . 

Tne next step in tne evolution was to develop graphics 
packages that were still specific for particular graphics 
devices but with a standard interface to the user program. 
This would allow transportation of user programs unchanged 
to installations where the "standard" interface was 
implemented. This development was moderately successful but 
by this time, areas of research had grown up around 
particular classes of graphics devices. User's of tne 
various classes of devices all had their own idea as to 
exactly what form the application program interface should 
talte. These opinions were widely varying and as always, were 
oriented toward the device capabilities. 
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Tne various scnools of grapnics researcn eventually 
realized that there were wide areas of agreement In their 
concepts of how a user should see a grapnics system. This 
led to the next evolutionary stride, the standardized 
graphics package. These types of systems were designed so 
that not only would the application program/package 
interface be fixed, but the functionality of the package 
itself would be unchanging. The need for individualized 
software for each particular device, however would not be 
removed. This task would be accomplished by a "device 
driver” and its interface with the standard package would be 
a fixed entity. 

The first meaningful steps toward a standard graphics 
package was the IFIP 'forking Group 5.2 Graphics 
Subcommittee's Workshop on Grapnics Methodology held in 
Seillac, France in 1976. Based on experience with existing 
machine and device independent packages like GINO-F and GPGS 
the subcommittee laid the groundwork for tne movement toward 
industry wide standardization. Their contribution was to 
outline and define tne issues that nad to be addressed if a 
standard was to become a reality. As already discussed, 
their prime concern was tne issue of application program 
portability. Toward this end their recommendation was that a 
study of the structure of application programs was 
indispensable, and that the results of such a study would 
drive the specification of a graphics standard. Another 
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outcome of tne Seillac meeting was tne assertion tnat tne 
separation of operations concerned with creating a picture 
of an object from those concerned with manipulating tne 
object itself was essential. Lastly, the Workshop urged that 
a standard graphics system specification not stand alone. 
Along with the detailed design should be included the 
methodology behind its development. 

In 1977 tne ACM Special Interest Group for Graphics 
(SIGGRAPH) appointed a Graphics Standard Planning Committee 
t® design an industry wide graphics standard. Using the 
recommendations of the Seillac Workshop as a foundation, the 
GSPC designed the CORE graphics system. Their specification 
for the system, and the methodology that led to it, were 
published in August 1977. An updated version appeared two 
years later incorporating the experience gained in the 
interim and extending CORE to raster devices. 



14 



III. ISSUES CONSIDERED IN core design 

In the early stages of discussion, tne Grapnics 
Standards Planning Committee concentrated on clearly 
defining their goal. Tneir objective was to design a general 
purpose graphics system tnat would meet the needs of the 
majority of graphics programmers and would be simple to 
install on most existing interactive displays. 

It is essential that such a general purpose system be 
simple. This principle was recognized by tne GSPC and 
strictly adhered to. They targeted their efforts toward the 
potential users with the intention of promoting well- 
structured, comprehensible software. Syntax was considered a 
less complex and secondary design issue. Tne committee also 
sought to put definite bounds on the scope of the new 
system. The intention was to provide a system tnat would 
offer a wide range of capabilities, but not at the cost of 
losing its appeal as a general purpose tool. Two tradeoffs 
that constantly cropped up before tne GSPC were simplicity 
vs. wide applicability and program portability vs. machine 
efficiency. 



A. FORMAT OF CORE 

The GSPC considered three approaches to development of 
the core system. One possibility was to create a complete 
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new graphics language. A second choice was to tafte an 
eiisting language and mafce tne core system an extension of 

it. The third approach, and the one finally settled upon was 
to build a package of graphics subroutines. There are a 
number of advantages to the subroutine pactcage as opposed to 
either of the alternatives. The major benefit is that it 
requires no changes to either the language or the compiler. 
System development, revision, and experimentation will have 
no effect on any other software at tne installation. Tne 
primary limitation is that the syntactic structure is 
extremely limited since the only choice in this area is the 
approach to parameter passing. 



B. DEGREES OF PORTABILITY 



The degree of program transp 
the type of required changes was 
general categories: 

1) The absolutely portab 
transferred from one Installation 
no changes whatever to the source 
the ultimate goal of any graphics 

2) Programs that require only 
modification of structure. This 
require adaptation to a new insta 
way that non-grapnlcs programs 



ortability as measured by 
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to anotner would require 
code. Such programs are 
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language have to be modified when they are transported. The 
changes typically are tnose necessary to adapt to such local 
idi osynchrasies as different character sets. These changes 
do not require a graphics programmer or a specialist in the 
particular application. Many of them can even be automated 
on a reasonably good text editor. 

3) The least portable category of programs would be 
those where changes to the program structure itself are 
required. Such changes as having to create a particular 
routine to draw an arc to replace a single command required 
by a more powerful device fall into this category. Changes 
of this type may require a detailed Knowledge of the 
particular installation characteristics; even then they can 
be somewhat difficult and nave a tendency to be error prone. 

Realization of the absolute portability goal, was not 
expected when the GSPC published their proposal. Tne 
immediate hope for the CORE system is that it will 
drastically reduce the number of changes required in an 
application program when it is transported. It is 
anticipated that the "routine” changes of category 2 above 
will be required in source code but, as a minimum, the 
structure of the source program should remain intact. 

C. SCOPE OP CORE 

Having established the form the roposed graphics 
standard would tame, and tne results that could be expected 
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from it, the committee set about defining tne scope of tne 
project. Recognizing tfte Seillac workshop's wisdom, tne GSPC 
focused on "viewing" as the essential part of any graphics 
system (its cor®, hence the name) and treated anything not 
concerned strictly with displaying information about an 
object as outside the scope of the standard. This is not to 
say that such issues as modelling or grapnic arts were 
ignored. The intent was to design a core viewing system 
upon which those functions dealing with abstract objects and 
relations between them could be built. 



D. VIEWING SYSTEM CONCEPTUAL MODEL 

Once the scope of their task was defined, the committee 
developed a model that would adequately represent their 
concept of the viewing system of tne standard. The viewing 
system can be thought of as a "synthetic camera" positioned 
and oriented in a user defined "world coordinate system". 
The display on the output device would be a "snapshot" of 
wnatever was in the camera's field. 

Such an analogy fit well the rules the GSPC had 
formalized. The "grapnical world" was considered all of tne 
graphical data available to the system, tfhat would show up 
on the output device would be a view of this world through 
the eye of the synthetic camera. The camera might be able to 
take in the entire set of graphical data or only a portion 
of it, depending on the viewing parameters. To take an 



18 



imaeinary snapshot, the system would nave to be aware of tne 
camera's location in space, its orientation, and tne amount 
of a particular object it could actually photograph (i.e. 
its clipping volume). Funner, at tne Instant tne snapsnot 
is talten, none of tne parameters related to tne object bein* 
pnotograpned could cnange. It must be remembered tnat wnat 
is on tne screen is only a part of tne total information in 
tne grapnical world. 

E. GRAPHICAL DATA STRUCTURE 

Besides deciding how to display an object in the 
grapnical world the committee nad to establisn the 
particular structure to be used to represent grapnical lata. 
The simplest approach would be to nave no structure at all. 
Either all of tne graphical lata is present and fixed or a 
new graphical world will have to be created. Thus, one could 
only build or erase an entire object. One displayed, there 
would be no changes to tne grapnical world. Such an approach 
is very easy to implement and storage is not a major issue, 
since after tne snapsnot is taicen, there is no further need 
of tne data. Such a system is ideally suited to hard-copy 
plotters and similar devices but its drawback is tnat it 
does not meet the needs of a large portion of graphics 
applications . 

Much of graphics is concerned with buildin<? an object 
and selectively modifying only parts of it. This requires 
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first, that the graphical data not be lost after it is 
displayed and second, that it be "segmented" in such a way 
that individual pieces can be manipulated. Since there is a 
considerable demand for such structuring, tne GSPC 
incorporated it into their standard proposal. Their concept 
is that graphical primitives (line drawing, text, and marker 
placements) be grouped into indivisible and unchangeable 
segments . These segments are then be combined to produce an 
entire object. Thus the picture can be modified by pieces 
through the deletion and addition of individual segments. 

In the Interest of economy and flexibility the CORE 
system also implements a form of the simpler unstructured 
option. For tne body of users concerned with storage 
efficiency or having hardcopy displays, it is possible to 
designate segments as tem p orary . A temporary segment is one 
that would generate graphical output while it is open, but 
once closed the segment would be automatically deleted. The 
next "new frame” action will cause it to be lost altogether. 
Effectively, while the image is being created in the open 
temporary segment the graphics system is unstructured. 

Another possible structuring of graphical data would be 
to use multi-level units to define tne grapnical world. In 
such a system, a "unit" (analogous to a segment) would be a 
collection not only of primitives but also of references to 
other units. This approach was considered by the G-SPC to be 
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to complex for the bulk of current graphics applications. 
There are many variations to its implementation, none are 
easily accomplished, and all require a great deal of 
bookkeeping overhead since a change to one unit may ripple 
through several others that reference it. It should be kept 
in mind, nowever, that if such a grapnical structure is 
desired it is possible to construct it using tne CORE 
sys tern. 

F. ATTRIBUTES 

With the structure of graphical data settled upon, the 
need arose for defining modifications to the described 
object. Besides the primitive functions already mentioned, a 
graphics system must have a means of further describing 
them. For example, a primitive like "line" might nave 
characteristics such as dashed (style), red (color), and 
double thickness (width). Deciding now to incorporate such 
into CORE was another major issue facing GSPC. 
Some attributes naturally associate themselves with 
primitives, like line style and width, while others Just as 
naturally only apply to wnole segments, such as viewing 
angle or clipping volume. A problem arises with attributes 
that are likely to be needed for botn primitives and 
segments. Color is a typical example. The ability to produce 
a drawing using lines of several different colors might be 
desirable. But if it is desired later in the program to 
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change the color of all drawings to say blue, an ambiguity 
arises in now to handle tne multicolored segment. 

The GSPC felt that resolution of such ambiguities within 
CORE would tase away from the simplicity of tneir system. 
Therefore they established the rule that no attributes would 
be snared. Attributes would be specific for primitives only 
or for segments only. The former would be "static" 
attributes and be unchangeable for a primitive once 

declared. Segment attributes, on tne other nand would not be 
so restricted. These "dynamic" attributes would be 
changeable to meet tne user's needs at any particular place 
in the program. 

The decision as to Just which attributes would be static 
and wnich would be dynamic were based on two criteria. Tne 
first being that primitive attributes would be those things 
that would normally be recorded by a snapshot of a 
particular object. Attributes pertaining to tne image as a 
whole would be segment attributes. The second criteria was 
that an attribute would be dynamic, (i.e. a segment 
attribute) only if most medium performance, refreshed 
display device architectures supported cnanging tne 
attribute with reasonable ease and efficiency. 

G. TWO AND THREE DIMENSIONAL GRAPHICS 

Along with the questions of graphical data structure, 
tne issue of now to treat two-dimensional and three- 
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dimensional grapnics in a single standard had to be decided. 
Initially tne inclusion of three-dimensional grapnics was in 
question since it necessarily would add complexity to the 
system. It was decided that the need for three-dimensional 
graphics was great enough that its exclusion would restrict 
tne applicability of the standard to an undesirable degree. 

& more subtle question than 3D inclusion was whether to 
treat 2D grapnics as a subset of 3D or to nandle the two as 
disjoint sets of operations. The advantage of disjoint 
treatment is that the 2D expression would not be 
unnecessarily complex since 3D information would not have to 
be carried with them. On tne other nand a large portion of 
the system's routines would have to be duplicated, one group 
specialized for 2D manipulation and anotner for 3D. 

The GSPC chose the subset approach in the interest of a 
unified treatment for all images. To foster simplicity in 2D 
graphics, they established that the z axis coordinate would 
automatically default to that of its last specified value 
when fitting 2D operations into the 3D format. 

3. VIEWING TRANSFORMATIONS 

One of the most difficult issues for the GSPC to decide 
was how to treat viewing transformations of an object. There 
are a large number of approaches to tnis problem and all 
have a certain amount of merit. When considering this 
particular question the committee chose to aim for maximum 
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system generality. Toward this end, they established four 
criteria. The first was that any viewing transformations to 
fie performed would fie declared before description of a 
particular object. No transformations within a segment would 
be allowed. Secondly, two-dimensional transformations would 
be upward compatible to three-dimensional ones. Third, all 
general planar projections would be possible to implement. 
Fourth, parallel and perspective projections would be 
consistent . 

In tne discussion of viewing it is necessary to go bacfc 
to the synthetic camera model. In order to maximize 
generality of the viewing aspect of CORS the parameters 
under investigation were those concerning the location of 
tne synthetic camera in space and tne location of tne 
viewing plane. The orientation of both the camera and tne 
viewing plane must also be considered. It should be apparent 
that the most flexible viewing system is the one that allows 
any orientation and any location for both the camera and the 
viewing plane. Restricting the positioning of one or both, 
limits the allowable viewing pyramid and results in failure 
to meet one or more of the established criteria. 

For example, suppose tne view plane were restricted so 
that it must always be normal to the direction in which the 
camera is aimed. In such a case, oblique perspectives are no 
longer possible, which is a violation the third criterion. 
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I. LEVELS OF CORE 

One of the final issues to be resolved was tne structure 
of the CORE standard itself. Tne question was whether to 
establish a single monolithic standard or to allow a number 
of "standard subsets" of a parent system. Realizing that a 
very extensive system might be well beyond the needs and/or 
resources of many installations, the GSPC settled on a three 
level structure. The lowest level would be restricted to the 
most basic needs of most users, stressing ease of 
implementation as well as economy of computing resources. 
The upper two levels include more features and a higher 
capability with correspondingly more difficulty in 
implementation. Each upper level of CORE includes all of the 
features of tne level below it. 
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IV. CORE SYSTEM DESCRIPTION 



A. OVERVIEW 

In the previous cnapter most of tne basic terminology of 
CORE has been introduced. In this chapter tne system itself 
is discussed in detail, but before doing so, more 
terminology must be introduced. Tne information displayed on 
the graphics display device is referred to as a 2i£i!i2is. The 
basic building blocks of pictures are output primitives. An 
output primitive is a line or sequence of lines, a non- 
drawing move of tbe cursor, a mariter placement, or a string 
of text. A number of output primitives are grouped together 
to form a segment. Each segment defines a single object and 
a combination of one or more objects defines an image. The 
vie w of an image can be thougnt of as a imaginary camera 
snapshot of it. To obtain a 3 -D projection of an image the 
user specifies tne imaginary camera position, type of 
projection (perspective or parallel) and where on the 
display surface the object is to appear. Different views are 
obtained by "moving" the synthetic camera in space relative 
to the stationary object. After the view of an image is 
determined the graphics system must map it onto the 
particular device selected to show it. The CORE system does 
this using two coordinate systems. Objects and images are 
created in a user defined, previously specified W or ld 
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Coord inate S ys te rn . Within this coordinate system the part of 
the total image that is to be displayed is framed by a 
window. The World Coordinate System is mapped by CORE onto a 
set of no r ma lized d evi ce c oo rdinates iNDCl. NDC 
specification defines the viewing area on the selected 
graphics device that will be used. NDC's are specified as 
fractions of the total available display widtn and height. 
The window and the visible section of the image in it are 
mapped to the corresponding location in the normalized 
device coordinates. Once the image is in in terms of the NDC 
it is a simple matter for tne CORE system, snowing tne 
particular device characteristics, to translate it into a 
picture on the screen. 

Any graphics system must nave a means of controlling its 
operating environment. In the CORE system this is 
accomplished by: 

1) turning clipping on or off 

2) selecting view surfaces for output 

3) setting initial values for segment and 
primitive attributes. 

4) establishing error handling mechanisms 

To support the control functions the application program is 
given the capability to inquire about tne system status, 
variables and device capabilities. There is a "new frame" 
function for screen clearing and a capability for grouping 
changes to the picture. 
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Output primitive functions may be referenced eitner by 
a segment identifier or a special ”picX-id" name. The picx- 
id is used in conjunction witn a picx device, wnicn will be 
discussed later in the chapter. 

To allow utilization by tne system of specific nardware 
and installation features, there is an escape mechanism. It 
is a standard, rigorously constrained function that allows 
the CORE system to taxe advantage of tne non-standard 
capabilities of its environment. Use of the escape has a 
price in that it taxes away from tne portability of the 
application program. 

B. OUTPUT PRIMITIVE FUNCTIONS 

Output primitive functions are the operations the 
programmer uses to describe objects in the device- 
independent World Coordinate System. Invocations of these 
functions are gathered into segments as drawing commands. 
Primitives wort from the c u rre nt position (CP) . which is a 
drawing location in world coordinates. It is simply a 
starting point for application of the function, and is 
initialized to the origin upon segment creation. 

There are five output primitives: single and multiple 
line drawings, text display, and single and multiple marXer 
placements. These are only slightly different for tne two- 
and three-dimensional versions. Coordinate positions may be 
specified as either relative or absolute, but tne former is 
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merely a notational convenience. It does not necessarily 
generate a relative positioning command to tne nardware. The 
concept of a marker in the CORE system is simply a 
designation of a position in world coordinates. A particular 
character appears on the view surface to indicate this 
position hut in world coordinates there is no such 
charac ter . 

Tnree kinds of text are supported by tne CORE system 
output primitives: string precision, character precision 
and stroke precision. The main purpose of string precision 
text is to supply information to the operator. Its 
generation is simple and efficient. Character precision text 
is used when it is important that a character string occupy 
a designated space, a plot axis, for example. String and 
character precision are also referred to as low and medium 
quality text, respectively. Both medium and low quality text 
output primitives take advantage of hardware character 
generators, if available. Stroke precision, or high quality 
text requires a different approach. Here, tne string is 
treated as if each line of each character were generated by 
software in the CORE system. 

C. SEGMENTS 

Segments are created in the applications program. 
Creation of a segment follows a simple sequence. Tne World 
Coordinate System is defined and normalized device 
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coordinates are specified. If desired, tne synthetic camera, 



discussed earlier, is positioned to establish the view of 
tne object. Next, a segment is "opened" and tne object 
described using the output primitives. After completing the 
object description, tne segment must be "closed ", To modify 
a piece of the picture a segment is deleted and a new one 
created to replace it. Segments are of two types: l) 
retained, wnicn are typically used for buffered displays and 
2) tem por ary, which are most often used by plotters. As one 
might infer, temporary segments are used only once to create 
a display and then are discarded. Retained segments are Jcept 
by the CORE system until specifically deleted. Temporary 
segments have the advantage of economy of memory 
utilization. A segment's type is established when it is 
created and remains unchanged for the life of the segment. 
Copying one segment into another or invoicing one segment 
from another is not permitted under the CORE system. 



D. ATTRIBUTES 



The effects of output primitives are 
assigning attributes to tnem. For example, 
"line" has an attribute "linestyle" which has 
and "dashed". Other attributes that apply to 
color, character size, character precision, 
more. 



modified by 
tne primitive 
values "solid” 
primitives are 
linewidth and 
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Segments, Hire output primitives, also nave attributes. 
These control such things as a segment's visibility, 
highlighting within tne segment and its detectability by a 
pick device. This last is a particularly important segment 
attribute. When a segment is detectable and a pick Is 
enabled, the device can select a primitive from tne segment 
and return to the application program both the segment name 
and the primitive's pick- id . 

With the exception of type, segment attributes are all 
"dynamic" in that they may be changed after the segment has 
been created. If tne user does not specify attribute values 
prior to segment creation, tne CORE system provides a set of 
default values. 

Segments are assigned attribute values from a table of 
current attribute values maintained by the system. The 
application program has the capability to interrogate and 
change attributes. For primitive attributes changes can only 
be made while the segment is open; segment attributes, on 
the other hand, may be changed at any time. A single 
attribute cannot apply to both primitives and segments. If 
certain attributes are not supported by hardware, the 
options are to either simulate them or force a reference to 
an error handling routine. The choice is installation 
dependent . 

Besides segment and primitive, attributes can be 
classified by the "space” in which they operate. For 
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example, text attributes describe tne text regardless of its 
location or orientation. They are said to define 
characteristics in "object space". On tne otner nand , line 
attributes such as style and width are related to views of 
objects. Depending on the location of the synthetic camera 
these attributes of an object may appear different for the 
same value. They are sail to operate in the "picture space". 



E. VIEWING TRANSFORMATIONS 

A viewing transformation accomplishes two tasfcs: it 
specifies how much of the world coordinate space is visible 
and it maps visible world coordinate pictures into 
normalized device coordinates. The viewing transformation 
ta&es a world coordinate volume (a clipped portion of a 
complete display) and projects it onto a view plane in world 
coordinates defined by a window. Tne projection is then 
mapped into a normalized device coordinate viewport, and 
finally to the physical device coordinates. The core system 
avoids a problem that nas occurred in the past where two- 
dimensional objects required different treatment. 2D objects 
are treated as a subset of the 3D objects. When a Z 
component is not specified, a default to the Z component of 
the current position is effected. 

Window rotation or inclination is a common requirement 
for many applications. In the CORE system the concept is 
implemented using a view-up vector. This vector simply 
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points to tne "straignt up" direction for tne window witn 
respect to tne world coordinate orthogonal X, T, and Z axes. 



F. INPUT PRIMITIVES 

Six types of input devices are supported by the CORE 
system : 

PICKS: identify an output primitive by its segment 



name and picic- 
LOCATORS : 
on the view su 
VALUATORS: 
KEYBOARDS : 
BUTTONS : 
alternatives. 

STROKES : 
application p 
Input for 
logical input 
abstractly in 
and controls 
CORE system's 
logical input 
will accomplis 
may be manipul 

1) Initial 

2) Enablin 



id. 

provide world coordinate values for a position 
rface. 

provide a scalar value, 
provide cnaracter strings, 
provide a means of selecting from several 

provide a series of positions to the 
rosrram in normalized device coordinates, 
interactive graphics is accomplished through 
devices. These devices are a specified 
the application program. The program defines 
them in a way unaffected by the hardware. The 
tasic in Interactive graphics is to connect 
devices to an available piece of hardware that 
h the desired function. Logical input devices 
ated in the following ways: 
ization/ termination 
^/disabling 
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3) Event queueing/ dequeueing 

4) Sampling 

5) Associating sampled and event causing devices (tnis 
ties values provided by sampled devices to events caused by 
event-generating devices) 

5) Echo control 

Logical input devices fall into two mutually exclusive 
categories. Tney are eitner sampled devices or event causing 
devices. Strode, picfc, keyboard and button are event 
generating devices; locator and valuator are sampled 
devices. Event-causing devices provide signals to tne 
application program. For eacn event, an event report is 
created containing data related to tne state of tne device 
at tne time of tne event. Tne CORE system enters event 
reports in an ev ent queue for later use by tne applications 
program. To get state information about sampled devices, tne 
application program must query tnem. Tnese devices do not 
generate event reports. A standard feature of tne CORE 
system is to ecno automatically all operator interactions 
unless tnis function is specifically deactivated. 

C. LEVELS OF CORE 

To meet tne wide range of installation capabilities and 
requirements, an upward compatible three-level structure for 
tne CORE system was selected. Tne aim was to accomodate wnat 
were considered the most common classes of equipment and 
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applications. Tne most basic level of tne CORE system deals 
strictly witn output. There is no interactive capability and 
the segments are of tne temporary type only. Tnis level 



consists of tne output primitives and tneir at 
viewing transformations and device controls. 

Tne next level adds tne ability to retain 
segments. It still is limited to output only opera 
visibility and nigniignting segment attributes 
included. Tne tnird, dynamic level, allows use of 
capabilities. Tnis is the level at wnich in 
graphics is supported. It provides all the 
intended to maice up the complete core system: 

1) Output primitives and their attributes 

2) Viewing transformations 

3) Device control 

4) Temporary and Retained segments and tneir at 

5) Input primitives 

5) Image transformations 

Level three is further divided according 
capability for image transformation: 

3A) Two-dimensional translation only 

3B) Two-dimensional translation, rotation and s 

3C ) Tnree-dimen sional translation, rotation and 
As with all of the levels, these sub-levels are al 
compati ble. 



tributes , 



selected 
tion. The 
also are 
the input 
teractive 
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so upward 



35 



Complications with such a level structure are lively to 
arise at installations wnere tnere is a combination of 
different grapples devices. What is envisioned for such a 
facility is a body of device independent code United to 
individual device drivers. The intent is to share as much of 
the independent code as possible, thereby iteeping as much to 
the objective of probability as feasible. 

H. ENVIRONMENT INTERFACE PROBLEMS 

Despite a great deal of effort to ma&e the CORE system a 
stand-alone entity, operating systems and programming 
languages still impact upon it. For instance, there is no 
standard way to maice device driver routines available to the 
application when the system is invoiced. Methods can vary 
widely depending upon computer and operating system 
capabilities. Another problem- is the case where a system 
message is sent to a terminal where the CORE system has been 
invoiced. The state of the display may be changed without the 
system being aware of it. The consequences of this depend on 
the situation, but system reliability will certainly be 
degraded . 

There is as yet, no definition of a standard interface 
with programming languages. It is hoped that as more insight 
and experience is gained, a standard language interface will 
be developed and the CORE system will be able to be invoiced 
from more than one language, adding a new dimension to its 
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portability. Input/output also nas 
prosramming language and the CORE 
the same device. Resolution of this 
and device dependent. 



problem potential 
system are operat 
is still highly 1 
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nguage 
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7. THE 7GM APPROACH TO CORE 



Tne 71rtual Graphics. Macn ln e XVGMj. Is Bell Northern 
Research's implementation of the CORE graphics system. It 
was developed on an IBM 3033 in ANSI standard FORTRAN and 
later modified to operate on a PDP-11/70 under the RSI-11 
operating system. 7GM is a FORTRAN based set of subroutines 
with each subroutine corresponding to a CORE primitive 
invocation, attribute setting, or view transformation. The 
package also includes subroutines for control purposes, such 
as initializing devices, opening segments and setting up 
coordinate systems. 

The intended customer market for 7GM is installations 
with low and medium cost ’’intelligent" terminals which are 
capable of generating graphical output from fairly high 
level functions and primitives. Terminals not accepting such 
high level input will require intermediate software to 
either simulate the functions or breai them down to lower 
level primitives compatible with tne device. 

Under RSI-11, 7GM exists as a library of FORTRAN 
subroutines. To use 7GM, tne application program is 
created independently as a main program making calls to the 
7GM library. The application source code is tnen compiled 
independently. The connection with 7GM is made by the RSX-11 
Tasfc Builder. The application object file and tne 
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appropriate routines from tne VGM library are linked into a 
single taslc by that RSX utility. 

Included in tne VGM library is tne particular subroutine 
that establishes communication between VGM and the selected 
device. This segment of code nas to be created specifically 
for tne installation where VGM is to be implemented. Tnis 
routine, SELSTR, is the only executable code in VGM that 
Interfaces with tne device driver. Grapnical data is passed 
between VGM and the driver via a COMMON blocs of memory. 
What SELSTR does is set tne necessary flags to control tne 
concurrency between the application tass (United with VGM) 
and tne selected device driver tasss. Each device driver 

exists as a separately compiled and United taste. Under RSX, 
before invoicing any driver from VGM these tasSs must be 
INSTALLed by the user. 

In VGM, syntax is a very minor issue. Since tne parent 
language is FORTRAN, and the entire system is based on tne 
subroutine call, the only syntax is the manner in which the 
necessary parameters are passed. 

It snould be emphasized tnat VGM does not implement tne 
CORE graphics system exactly as set down in tne 1979 GSPC 
report. There are a number of differences, wnlcn may be 
grouped into four general categories. 

A. FUNCTIONAL DIFFERENCES 

In this category the end result of a series of 
operations in VGM is the same as that specified by CORE but 
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the mechanism for achieving the result is not the one 
specified in the proposal. 

1 • Segme nta tion 

The CORE system creates a retained segment or a 
temporary segment with a single function specific for the 
particular segment type. VGM uses a two-step process. First, 
a segment type is established. After the invocation of the 
routine to do this any segment created will take on the type 
of the one declared. All segments created will be of the 
same type until a new type is declared. 

Retained segments in 7GM are stored in Transformed 
Pi splay Fli e s LlQZl.ll • The TDF contains graphical 
information that is ready to be translated into a device 

compatible format. All clipping and transformation has been 
done before the data is entered in the TPF. Should the 
application program specify an operation on a segment, the 
entire TDF is likely to be changed. Segments that are 
specified to be temporary do not cause creation of a TDF. 

2 • Attributes 

Like CORE, VGM partitions attributes according to 
their application to either segments or primitives. Both 
systems further divide the set of attributes according to 
their changeability within the program, dynamic attributes 
being those that are subject to change by the application 
program after their initial declaration and static 
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attributes being those tnat are not. In CORE tnere are no 
dynamic primitive attributes. VGM, however, does have a 
group of primitive attributes that it labels as "dynamic”. 
Each member of the set of 7GM dynamic primitive attributes 
is also a member of the set of static primitive attributes. 

In 7GM a static primitive attribute is one that is 
set while a segment is open, and that once declared, applies 
to all appropriate primitive invocations following it until 
the segment is closed. Further, for the lifetime of that 
segment it will always apply to the set of primitives 
created with it. A static primitive attribute cannot be 
overridden by any other setting of that attribute anywhere 
in the program. 

If no attributes applicable to a particular 
primitive are set within a segment then dynamic primitive 
attributes may be assigned outside tne segment. At a later 
tim^ in the program these attributes may be changed. When a 
dynamic primitive attribute is set, the segments to which 
the change applies must be specified. If the application 
program does not set either dynamic or static attributes for 
some primitives then default values are used. It is also 
possible for the user to specify his own set of default 
values . 

The applicability of an attribute to a primitive at any 
particular time in the program can be determined by the rule 
that user specified dynamic primitive attributes always 
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override default values and static primitive attributes 
always override dynamic ones. 



3. The Viewing Su rface 

The flow of graphical information from a segment to 
an output device is viewed by VGM as a "stream". By 
manipulating streams, tne user carries out tne CORE 
SELECT/DESELECT and EN ABLE/DISABLE device operations. In VGM 
wnen tne user initializes a stream, ne is picking a 
particular device or group of devices for output. Devices 
are assigned to a specific stream as part of VGM. A given 
stream may have more than one device associated with it. 
Changing this assignment requires changes to the VGM source 
code itself. Stream initialization by the user's subroutine 
calls accomplishes the necessary operating system functions 
to linfc VGM and the appropriate drivers. It is valid for 
more than one stream to be in use at any given time. 

After initializing the required treams the user 
then selects one or more of them to be used for display. 
Once a stream is selected, all subsequently generated 
graphical output will be displayed on the devices assigned 
to that stream until it is deselected. There is no way to 
address individual devices on the same stream. Stream 
operations are not allowed while a segment, regardless of 
type, is open. 
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- • Co o rdina te S yste ms 

7GM uses an extra coordinate system in translating 
grapnical data from world coordinates to tne terminal 
Phy sic al Device Coordinates i£DC2 . Between the 
transformation from World Coordinates to Normalized Device 
Coordinates, VGM taxes clipped graphical data and maps it 
onto a view plane in View Plane Coordinates ilPCl. The flow 
of graphical data is shown in Figure 1. 
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Figure 1. Flow of graphical information through coordinate 

systems 



5 . Tran s f or mations 

In the CORE specification there is a static segment 
attribute called IMAGE_TRANS FORMAT I ON_TTPE this specifies a 
maximum allowable level of transformation that can be 
applied to a given retained segment. Tnere are four 
allowable levels: 

a. no transformation 

b. 2D translation only 

c. 2D translation, rotation and scale 

d. 3D translation, rotation and scale. 
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This feature is not included in 7CM. The transformations of 
2D or 3D translation, rotation and scaling nay be applied to 
any retained segment at any time in the program. 

5 • Tex t Manipulations 

In CORE, the manner in which text is displayed on a 



device is 


controlled 


by, 


among 


others, the 


att ri butes 


CHARPATH, 


CHARJUST, 


and 


CHARUP. 


The first 


attri bute 


specifies 


one of four 


paths 


in the 


view plane: 


up, down, 


right or 


left. As the 


sequence of 


text is output 


CHARPATH 


determines 


where in relation 


to the 


last character the next 



is to be positioned. The first character is always 
positioned at the CP. The CHARJUST attribute is a 
combination of directions, again in the view plane, which 
Indicate where, in relation to the CP, the rectangle defined 
by the output text string is to be placed. Figure 2 gives 
the possible CP locations. 



top 

center 

off 

bottom 



left center right 

i i i 




Figure 2. Possible position designations of CHARJUST 



The text, depending upon the charjust values will be placed 
in such a way that the CP will be at a junction of a 
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vertical and a Horizontal line. A particular Junction is 
identified by its Horizontal and vertical position labels, 
e.g. "left, top" = point a; "center, off" = point b. Tne 
CHARUP attribute is a vector from the origin in World 
Coordinates which specifies the "up" direction for the text. 

These three CORE attributes are not specifically 
implemented in 7CM. Instead, their functionality is included 
in the 7GM attributes CHARPLANE, CHARSIZE and CEARSPACE. The 
teit string orientation is defined by the CHARPLANE (a 
vector in World Coordinates originating at tne CP) and a 
"string extent” vector. The string extent vector is obtained 
from the CEARSPACE and CEARSIZE attributes. Fieure 3 
illustrates the components of these two attributes. 
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a = CHARSIZE x component 
b = CHARSIZE y component 
c = CEARSPACE dx component 
d = CHARSPACE dy component 

Figure 3. CHARSIZE and CHARSPACE attribute components 
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The string extent is tne result of multiplying the vector 
'V ' by the number of characters. ' 7 ' originates at the CP. 
The boxes containing the text characters will be in the 
character plane with their lower left corner on the string 
extent vector. 1 wide variety of directions the text may 
follow stems from the fact that values for the attribute 
components can be positive or negative. 

7 . Risibility 

In CORE tnere is a segment attribute called 
VISIBILITY which, if "on", means to display a specified 
segment on the output device and, if "off”, to remove it 
from the screen. This capability also exists in VGM where a 
segment may be POSTed to maice it visible or UNPOSTed to 
remove it from the picture. 

B. CORE FUNCTIONS NOT IMPLEMENTED BY VGM 

The following list of CORE functions are not implemented 
at all in VGM: 

1. pen attribute 

2. mar!cer_symbol attribute 

3. picfc_id attribute 

4. naming of primitives 

5. viewjip vector 

6. some inquiry routines 

7. terminate_, disable^, and enable_group routines 

8. batch update 
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9. escape mechanism 

10. highlighting 

11. hierarchical level structure 

12. acceptance of asynchronous input 

C. FUNCTIONS IMPLEMENTED BY 7GM NOT IN CORE 
SPECIFICATION 

1 • P ri mitives 

The following primitives have been added to 7GM: 

a. rectangle 

b. a rc 

c. polygon 

d. flood 

The flood primitive is for use with bit mapped, 
color devices. Flood locates the CP and establishes the 
smallest area surrounding it bounded by arcs or lines. This 
area is then filled with a user specified color. If the CP 
is not enclosed then it is possible to flood tne entire 
display surface. 

2 . Attr ibut es 

For terminals capable of color graphics 7GM adds a 
B AC KGROUN DECOLOR attribute and an ADDITI7E_MODE attribute. 
The former is self explanatory. The latter determines how a 
declaration of any new color attribute is to be treated. If 
ADDITI7E_M0DE is "on" then the bit pattern for the old color 
is logically ORed with the bit pattern for the new color, 
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and tne resulting pattern becomes tne value of tne 
attribute. Ot&ervise the new color bit pattern simply 
replaces the old one. 

1 BLINK attribute is implemented in VGM, wnicn is 
intended to be one method of replacing the CORE system 
HIGHLIGHTING attribute which has been left out. 

3 • Other Fgaiu res 

In 75M , there is a mechanism for modifying a 
segment after it has been closed. This is the EXTSEG feature 
which effectively re-opens the segment and allows additional 
graphical information to be appended to the existing file. 
The feature only allows addition of information and requires 
that the CLOSEG command be issued after the addition is 
complete . 

If a graphics device that is currently in use has 
both input and output capabilities, VGM will, if directed by 
the application program, "bacic transform" input coordinates 
from Physical Device Coordinates to World Coordinates. CORE 
will only bacJr transform to Normalized Device Coordinates. 

VGM's error handling and debugging aids offer more 
than is required by the CORE proposal. In VGM tne user has 
the capability to specify tne maximum tolerable error 
severity and the maximum tolerable number of errors. If 
either maximum is exceeded, tne program will terminate. Wnen 
errors are detected, an entry is made into an error trace 
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file. This file is intended to be a debugging tool. It 
contains the error code number, a brief description of tbe 
error, the relevant parameters involved in the error, the 
name of the routine in wnicn the error was detected and the 
result of the error (corrected, ignored, default 
substitution or program termination). 



how to treat non-graphl cal data sent to a terminal being 
used for CORE graphical output. Typically, this might be 
parent language I/O in the form of write statements or a 
system message to the particular terminal. In VGM there is a 
SET_POS ITION function which identifies an NDC position 
specifying where non-grapnical output is to appear on tne 
screen. This output is affected by neither attributes nor 
the CP. 

D. EQUIVALENT FUNCTIONS WITH DIFFERENT NAMES 

Tnis is tne simplest category of differences between 
CORE and VGM. Below is a short list showing equivalent 
functions in CORE and VGM. 



An option that GSPC left open to imp ementors was 



CORE name 



VGM na m e 



cnarpreci sion 



cnarquali ty 



detectabili ty 



pickability 



highlighting 



blinK 



world coordinate 

transformation 



modelling transformation 



49 



71 • THE VGM DEVICE DRIVER 



The device driver is tbe connecting lins between VGM and 
graphics hardware. Its purpose is to tate grapnlcal data 
from VGM via the designated COMMON storage area and 
construct an instruction in a format compatible with tbe 
particular device it is written for. Tbe software for tbe 
device driver is divided into 6 modules. 

A. THE DEVICE CHARACTERISTICS TABLE 

This table is a COMMON blocs of variables describing the 
characteristics of the graphics device for which the driver 
is written. It is Implemented as a BLOCK DATA source program 
and is accessed by all of the executable modules of the 
driver. It is initialized when the module is compiled and is 
treated as "read only" by all of the routines referencing 
it . 

B. THE STREAM INFORMATION TABLE 

This is anotner COMMON blocs of data which holds the 
current value settings for attributes for each stream. The 
table is updated by the driver routines as the values are 
changed. When the BLOCK DATA source file is compiled, the 
default attribute values are set. 
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C. THE RUN TIME INFORMATION TABLE 

This table, lilce the stream information table is subject 
to continuous update by the device driver routines. It 
contains the buffer that holds the instruction to be sent to 
the graphics device. Pointers required for Keeping current 
positions in the instruction buffer (CODBUF) are also in the 
run time information table. In addition there are variables 
for the identification of the debug file and several host 
computer related values. 

D. ROUTINES EXECUTING 7GM PRIMITIVES (OnLIBl) 

This module is executable code that is intermediate 
between 7GM and the device instruction creating portion of 
the driver. Its routines are invoiced from 7GM and it in turn 
calls routines to create the appropriate data to fill 
CODBUF. OnLIBl is graphics device independent but is host 
machine dependent. Contained in OnLIBl is the OnEXEC routine 
that is tne only executable code in the driver software that 
communicates with 7GM. 

E. DEVICE INDEPENDENT LIBRART OF SHARABLE ROUTINES (SKELIB) 

This collection of routines is a set of device 

independent operations that are optionally available to 
OnLIBl. These routines perform operations like projection on 
a plane, clipping, image transformations, line style 
generation etc. For highly capable devices which perform 
these tasics themselves OnLIBl would not reference SKELIB but 
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instead cause the specific device instructions to oe 
generated. For devices that laclc some of these features in 
hardware, SOLIB provides software simulation. 



F. DEVICE DEPENDENT ROUTINES GENERATING INSTRUCTION CODES 
(0nLIB2) 

This set of subroutines fills the instruction buffer 
witn instructions and data specifically formatted for tne 
target device. Each byte of CODBUF must be precisely set to 
be compatible with the graphics device. 0nLIB2 builds tne 
full instruction and, when complete, causes it to be sent to 
the terminal. The communication with the terminal is done 
with MACRO routine QWRITE which uses the host computer's I/O 
communication facilities and treats the graphics device as 
an I/O port. 
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Fisrure 4. Interrelationship of Device Driver Modules 
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vii. REsgLis AND suggestions for ngigsE siudi 



A. SOFTWARE 

As stated In tne introduction, tne purpose of tnis 
research was to lay the groundwork for a detailed study of 
the CORE graphics system. A great deal of progress has been 
made in this effort. Tne 7GM implementation of tne CORE 
system is installed at the Naval Postgraduate School and is 
capable of operating with the Tektronix 4014 storage tube 
display terminal. The system has passed the initial stages 
of testing. Additionally, algorithms nave been developed and 
implemented on a limited basis for expanding the VGM 
software to interface with tne Ramtek RM-9400 graphics 
system. These portions of the project are discussed in 
detail in Appendices A and B respectively. 

A less tangible, but equally valuable result of this 
study is the experience and insight gained with both CORE 
and the VGM implementation. Appendix C is one product of 
this new knowledge. It is a brief tutorial on programming 
with VGM and is written specifically for the Naval 
Postgraduate School installation. The tutorial is not 
intended to replace the Bell Northern Research User's 
Manuals. It is meant to be used in conjunction with tnem and 
deliberately avoids details which can easily be found by 
referencing them. 
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B. CORE EVALUATION 

The CORE system is currently only a proposal and as such 
it is intended for thorough scrutiny by the graphics 
community. In researching tnis subject a number of issues 
have been Identified which may provide a framework for an 
evaluation of the system. This collection does not purport 
to be exhaustive but is presented to provide a base for 
future wortc. 

1 • P or t abll l ty 

The prime issue to be evaluated is that of program 
portability. This has already been discussed in depth in the 
GSPC proposal and summarized in this report in Chapter III. 
In the course of this study some different perspectives on 
the problem have come to light. It appears that there might 
be hierarchical levels of portability other than those 
listed in the GSPC report. Graphics devices, computing 
systems, operating systems and CORE Implementations are all 
variables in this area. Another way of classifying the 
portability of a program might be in terms of these 
environmental factors. For example, some programs may be 
portable from one device to another as long as the computing 
environment is not changed. Others may survive a change of 
computing machinery provided the operating systems are the 
same. Conversely, changing operating systems rather than 
computers might be the defeating factor in a program's 
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portability. let another possibility is that different 
implementations of CORE may be tne reason for changes in a 
given program. 



It would 
issue from 
environments 
presentation 
when such 
considered. 



be difficult to develop furtner the portability 
this point of view until a variety of 
exist for side by side comparisons. The 
of this perspective is recorded here so that 
facilities are available its validity can be 



2 . Imp l em e ntat ion Effo rt 

To gain widespread acceptance the CORE system must 
be easy to implement. Criteria are needed to measure the 
difficulty of implementation. The following list presents 
questions which may serve as possible evaluation mecnanisms 
for this: 

a. Can the implementation be reduced to simply 
following some kind of implementation 
"algori thm”? 

b. Does the design of the implementation 

favor one type of device over another? 

c. Does the design of the implementation 

favor one computing environment (either hardware 
or operating system) over another? 

d. What tradeoffs in portability have to be made so 
that implementation can be facilitated? 
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3 • Dev i ce Ca pa bility 

As is true of almost all standards in the computing 
industry the CORE system does not taice full advantage of the 
hardware capability of many installations. It was never 
intended to meet all possible needs. Nonetheless a means of 
assessing the loss in device capability under tne CORE 
system should be established. A guideline for determining 
wnen the gains from using CORE are outweighed by the losses 
from not utilizing the full power of the device would be a 
highly desirable tool, particularly for facilities 
generating a wide range of graphics applications programs. 

4 . COR E Capa bl 1 1 ty 

Perhaps tne most difficult and controversial 

question in the evaluation of CORE is whether its 

capabilities really are sufficient for most grapnics 
programmers. Eurther, how adaptable to future needs will the 
system be? Is hardware technology lively to progress to a 
point where CORE is no longer adequate as a standard? Is it 
lilcely that computer graphics will expand into areas that 
CORE was never intended to serve? Certainly none of these 
issues will be resolved easily. Each question in itself 
could be a topic for detailed analysis. They are presented 
here Just to suggest areas for further study. 

C. OUTLINE OF CONTINUING DEVELOPMENT OF THE NPS SYSTEM 

In the course of this study some ideas have been 
formulated for a methodology to direct continuing worse on 
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toe project. This is only one worker's point of view and it 
should serve as a guide rather than an absolute to follow-on 
workers . 

1. VGM 

The first order of business should be to modify the 
Bell Northern Research test routine, AXPAK , so that the full 
range of 7G-M functionality can be verified. Tnis would 
entail construction of appropriate overlays for tne test 
package so that the large amount of object code can be 
accomodated on the limited PDP-11/50 memory. Once tnis is 
accomplished, AXPAK can serve as a benchmark program for 
testing additional drivers that are added to 7G M. Using 
AXPAK as a benchmark should also aid in studying other 
portability issues. 

2 • Device Drivers 

The pattern for writing tne code that interfaces tne 
device independent portion of a software driver and the RM- 
9400 has been established. Further, it has been partially 
implemented and tested. The next step is to complete the 
remaining subroutines in the 04LIB2 (device dependent 
routines) module according to the algorithms provided in 
Appendix B. Once a new 04LIB2 nas been built it can be 
incorporated into 7GM and tested, first as a separate entity 
using the provided DDTEST program and then as a fully 
integrated part of VGM using 1 AXPAK. 
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By no means would tnis complete woric on tne Ramtex 
driver. After tne 04LIB2 woric is completed tne driver would 
still fall far snort of taxing full advantage of tne power 
of the RM-9400. A topic of study all its own would be the 
modification of tne "device-independent” sections of tne 
driver code to put the sophisticated features of the RM-9400 
into use. 

An ancillary project would be to develop yet another 
driver for a new graphics device. The object of this study 
would not be to merely expand the capabilities of tne 
existing VGM system. What it is hoped would emerge from such 
research is a pattern for writing device drivers. Such a 
formula, if it exists, would be a very useful tool for 
further expansion of VGM without the necessity of re- 
learning already established techniques. 

3 . Por tability 

With a fully operational VGM system and a variety of 
devices available for use, portability testing can begin. 
The suggestion is to direct the woric along lines mentioned 
earlier in this chapter in section B. After varying the 
graphics devices and studying the system behavior over a 
variety of them, woric should proceed to studying program 
behavior under cnanges in the computing environment. Other 
operating systems, other computers, and other CORE 
implementations are available for such research. This 
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APPENDIX A. IMPLEMENTATION OF VGfj AT NAVAL POSTGRADUATE 

SCHOOL 

The aim of this portion of the project was to gain 
insight into the operation of VGM and to install a wonting 
version of it on the Naval Postgraduate School's graphics 
facility. Bell Northern Research (BNR) of Ottawa, Canada 
supplied the school with a tape containing the source code 
for VGM, version 1.1. and two device drivers. One driver was 
written for a Chromatics color graphics, raster scan 
terminal and the other for a Tektronix 401X storage tube 
terminal. A Tektronix 4014 was readily available at Naval 
Postgraduate School and, being a simpler device, was deemed 
the best choice for installing and testing VGM. 

On the same tape as the VGM and device driver software 
were several command files to aid in installing the system. 
These command files did such things as compile the source 
modules, install libraries and build tasks. Their inclusion 
was intended to save some user time and effort and to help 
avoid erroneous or incomplete system commands that might 
arise during any of the initial stages of software 
installation. 

The plan for implementation was the following: 

A. Compile all of tne source modules making up VGM. 
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B. Convert the VGM object code into a FORTRAN library under 
RSX. 

C. Compile all of the source modules making up the Tektronix 
device driver. 

D. Link tne object code from tne device driver compilations 
into a single task called 02DRIV. 

E. Test tne driver separately from 7GM by using a test 
routine supplied by Bell Northern Research. 

F. Install 02DRIV under RSX as a task available for 
concurrent use. 

(r • Test 7GM itself using tne Bell Northern Research supplied 
test graphics program AXPAK. 

Before any of tne installation could begin, tne software 
on the tape had to be made easily accessible. This was done 
by copying it onto tne RSX on-line disk storage. A copy of 
the BNR software may be found under directory DP0: [201 ,211] . 
This copy of tne source code is intended to remain unedited. 
Any chansres to the code during 7GM Installation were made by 
transferring original copies to a working directory and 
editing there. To generate object code the modules necessary 
for 7GM and the device driver compilation were PIPed to 
directory DP3: [201, 210] . Once the source code was available, 
the command file VGMCOM.CMD was executed. 7GMC0M.CMD had to 
be modified somewnat to make it compatible with tne F4P 
compiler. The BNR software was written under an older PDP 
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version of FORTRAN so tne compiler commands dad to be 
adjusted accordingly. 

In all, VGM contains 12 output modules and 7 input 
modules. Each module is, in turn, made up of several 
subroutines grouped by the particular function they perform. 
For example, the output module INISTR (iNItialize STRing — 
named for the first of the component subroutines) contains 
16 separate subroutines all having to do with either stream 
or segment manipulations. There are also two block: data 
modules and a test program. 

Once object code was generated for all of tne VGM 
routines, command file 7GMLIB.CMD was executed under the RSI 
LIBRARY utility, creating a library of all the executable 
routines concerned with input and output. 

The compilation process was repeated for the source code 
modules for the Tektronix driver. Command file 02DC0M.CMD 
accomplished this. The device driver modules consist of two 
"libraries" which manipulate the device independent 
information coming from VGM. A third library, 02LIB2, does 
the actual creation of instructions to the Tektronix. 02LIB2 
is the portion of the device driver that linlcs VGM and the 
terminal. There are also some bloclc data modules which set 
up communication areas between the device driver and VGM and 
also provide specific device parameters where needed to both 
VGM and the device-independent portions of the driver. Two 
MACRO modules are included to handle input and output 
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communication between the device and the operating system. 
The rest of the driver related modules concern themselves 
with interfacing the device independent parts of the driver 
and 7GM itself. 

Lite 7GM , the object code for the device driver modules 
are built into a library under RSX by file 02DLIB.CMD. Tnis 
library however is only a temporary holding area for the 
driver object code. It is referenced by tne file OSDRIV.C^D 
and the object modules are linked together into a single 
tasic called 02DRIV. 

With 7GM eiistlng as an object library and 02DRI7 as an 
individual ta sir the preliminary wort is done. Testing is 
accomplished in two stages. The first is testing the 
functionality of the device driver independent of 7GM . The 
test program, 02TEST, was provided by Bell Northern Research 
and was compiled with the rest of the driver routines and 
bloclc data programs. The file 02TEST.CMD Units tne test 
program, the driver library, and the bloct data into a 
single executable tast called TEKTEST. TEXTEST exercises tne 
driver's functionality fully and is available for use in 
directory DP3: [201,210j . 

After tne driver was satisfactorily tested alone, tne 
tasic 02DRI7 was INSTALLed under RSX. The INSTALL feature is 
an RSX utility that activates a specified tasic and mates it 
available for invocation from another active tasfc. 
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The next step is building the VGM test task. The test 
routine, AKPAK, is also supplied by BNR and is intended to 
thoroughly test VGM and any selected device driver. The 
command file provided to build the AKPAK task: is VGMTO.CMD. 
The initial attempts to build the test program resulted in a 
Task Builder diagnostic indicating that not enough 
contiguous disk space was available for the AKPAK task. This 
was partly a result of the fact that AKPAK and the 
associated VGM library routines require a very large block 
of disk storage. This is also indicative of another 
potential problem. Since the AKPAK test is such a large one 
it is not likely to fit into tne available core memory. It 
will most likely require construction of overlays to run on 
the limited memory resources of the PDP-11/50 at NPS . 

It was decided that at least for the initial phase of 
study to follow a somewhat shorter and simpler testing path. 
Rather than become involved in constructing overlays and 
possible changes in the structure of AKPAK, a more limited 
test program would be written. Since one goal of this part 
of the work was to set an operational VGM system it was 
decided to at least ensure the proper interfacing between 
the user program, VGM and 02DRIV. 

Toward this end, a much simplified test program was 
written, called VGMTST. It was linked witn VGM and tne 
necessary block data routines by file VTST.CMD. VGMTST 
exercised several of the 2-dimensional drawing, move, and 
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marker primitives, the low quality text capability and the 
SET_POS ITION feature. In addition, some of the device and 
segment control functions were also tested since their use 
is essential for any VGM operation. 

The execution of VGMTST was quite successful. The 
drawings on the Tektronix screen appeared as expected. The 
taslr is available for use under directory DP3: [201 ,210] . To 
use the test routine, turn on the TeKtronix 4014 and log in 
under SSI by the standard procedure. Enter the proper 
directory by typing 

SET /UIC = [201,210] 

after the RSI prompt ( > ). Next, wnen tne prompt appears 
issue the commands 

>1 NS 02DRIY 
>R0N YGMTST 

The test program will execute and tne resultant grapnics 
will appear on the screen. 
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APPENDIX B. CON£TgO£TION QF 4 DEVICE DRIVER FOR THE RAMTEK 

RM-9400 

A. DEVICE DRIVERS 

Bell Northern Research's device drivers are identified 
by unique integer designations, the particular integer being 
incorporated into tne driver name and tne names of tne 
modules that comprise them. The modules, and subroutines in 
them, specific to the Chromatics driver all begin with an 
01- identifier, for example, 01LIB2 or 01M0VE. The Tektronix 
4014 software is device driver # 2 , tnus its names are all 
prefixed with an 02-. Also provided is a driver which shares 
the Tektronix 4014 code but is to be used with tne Tektronix 
4010. This uses the 03- prefix. Only the 03EXEC (the 
interface with tne VGM software) routine has tne prefix, the 
rest of the driver uses the Tektronix 4014 code. For the 
routines to be written as part of this study, tne 04- prefix 
was selected, being the next in the sequence. 

The target device in this portion of the study was the 
Ramteic RM-9400, a very powerful and sophisticated color 
raster scan graphics device. Adaptation of a similar driver 
seemed the best course of action. The Chromatics grapnics 
terminal is also a color, raster device though not nearly as 
advanced as the RM-9400. Nonetheless its driver is readily 
available and is already adapted to the PDP-ll/RSX 
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environment. It provides a good starting point for 
developing tne Ramtefc software. 

The initial intent in tne construction of a device 
driver for tne RM-9400 was to leave tne Cnromatics driver 
intact as far as possible. Tne module SKELI3, wnicn contains 
tne device independent hardware feature simulation routines, 
was left unchanged. Tne Stream Characteristics Table had to 
be modified only slightly to include the new device. The Run 
Time Information Table for tne Ramtet is simply a copy of 
the one provided for the Chromatics driver. The same is true 
for 04LIB1 witn the exception of tne 04EXEC routine. 
Modifications to 04EXEC were very slight. Inclusion of the 
new 04EXEC routine did necessitate cnanges to tne 7GM 
software in the INISTR and SELSTR (SELect STRing) modules. 

The bulS of the worlc in writing tne new driver will be 
in developing a new 04LIB2. Creation of a new Device 
Characteristics Table is also important. The latter requires 
an item by item reviewing of tne table variables and 
providing the appropriate values as they pertain to the RM- 
9400. Details of what entries should be made are in the BNR 
"Skeleton Driver Installation Manual". In this study very 
little of the RM-9400's capabilities were exercised and the 
importance of the Device Characteristics Table was secondary 
to getting a rudimentary system in operation. As the device 
driver develops into a more refined form and incorporates 
more of tne RM-9400's capabilities, tne Device 
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Characteristics Table should be reviewed and updated 
continuously. 

B. RAMTEK RM-9400 INSTRCTCTION FORMAT 

Before writing any of the routines, a knowledge of the 
format of an RM-9400 instruction is required. The RM-9400 
instruction is a variable length buffer of 16 bit words. The 
first 8 bits of the first word contain the code for the 
function the device is to execute. For exa pie, an operation 
code of 06H (Ramtefc mnemonic INIT) initializes the device? a 
code of 35H (Write Fector, Cnlintced — mnemonic WVTJ) is a 
line drawing instruction. The operation code determines how 
much more of the instruction buffer the RM-9400 needs. For a 
very simple instruction lifce INIT, once the operation code 
is read, the rest of the buffer is ignored. For something* 
like a line drawing, however, the device will require a 
number of extra words of information before it can execute 
the instruction. The extra words will, as a minimum, have 
to indicate the end points of the line, and may include the 
foreground and bacisround colors as well as the line style 
and thickness. Depending on the operation, some of the 
additional instruction words are essential and some are 
optional. In most cases, if a piece of data is required and 
is not specified, a default value will be used. The 
architecture of the RM-9400 is sucn that it is possible for 
the user to specify the default parameters values. 
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The presence of additional words of information is 
indicated to the Ramtefc by flag bits. The last 8 bits of tne 
first word are the primary set of flags. Only three of these 
are involved in extending the size of the instruction. The 
five high order bits of the low byte modify the execution of 
the operation code as indicated in the following table. 



bits 6 & 7 
bit 5 
bit 4 
bit 3 



code for the mode of addressing 
refresh memory 



selects additive 
text output 



mode 



of 



reverses foreground and 
background colors 

sets device to process 

bytes in a word in reverse order 



It is the tnree lowest bits that indicate how many 
additional words of data will be in tne instruction. Bits 2 
and 1 each indicate whether a particular "operand f la e word” 
will be in the instruction buffer. 

If bit 1 in set, "operand flag word #l” (OF1) will 
immediately follow the word containing the operation code 
and the primary fla*s. 0F1 is another set of fla^s each of 
which corresponds to additional pieces of information in the 
instruction. The settine of one of the 16 bits in OF1 means 
that one or more words of data will follow. The order of the 
additional data will correspond to the bits of 0F1 , from 
lowest to highest. 

A sample bit pattern might be 

0000 0001 0000 0010 ( 0102H ) 
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This would indicate that two additional pieces of data (one 
for each "l" bit) are in the instruction buffer following 
OF1. In this case the two bits that are set mean that 
"foreground" data and "line dimension" data are present 
(bits 1 and 8 respectively). The foreground information is 
simply an integer index to a color table in Ramtefc refresh 
memory and only requires a single word of storage. The line 
dimensioning information is more complex consisting of a 
pattern code and a repeat code (interpretation of these 
codes is not important to the current discussion) and 
requires two words. These two words will follow the 
foreground word in the buffer. The code that the RM-9400 
would execute is shown symbolically in Figure 5. 



bit 15 



bit 0 



j op code | 


flags j 


! operand flag 


word 1 


foreground color index ! 


! line code 


word 1 ! 


! line code 


word 2 | 


* — ______ _ 


— — — — 1 



Figure 5. Instruction Buffer with 0F1 and Associated 

Parameters 



Bit 2 of the primary flags indicates the presence or 
absence of "operand flag word 2" (0F2). If flag bit 2 is set 
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then 072 will immediately follow 0F1 . If flag bit 2 is set 
and flag bit 1 is not, tnen tne word immediately following 
the operation code word is 0F2. 0F2 performs exactly the 
same tast as 0F1 except tnat only its six least significant 
bits are used. 

Fla* bit a in tbe operation code word indicates that 
text or numeric data will follow OFl, 0F2 and their 
associated parameters if present. The first word of tnis 
data will always be an integer indicating now many 
additional bytes of data will come after it. 

To illustrate, suppose the user wants to draw a line 
from the pixel at screen coordinates 12>0,100 to the one at 
500,500. He further want its color to be tnat of #4 in tne 
color table in refresh memory and his line dimension code is 
given by the words 0101E and 0003H. The instruction buffer 
would be that shown in figure 6. 

To a rousrh approximation the operation codes for R v !-9400 
instructions correspond to VGM primitive and device control 
functions. Similarly, the parameters referenced by the 
operand flag words correspond to attribute values. While 
this is not always the case it provides a good rule of thumb 
for tne initial development of a device driver. Those VGM 
calls executin* a primitive or control function will cause 
an operation code to be placed in the instruction buffer. 
Those settin* an attribute will cause the settin* of flags 
and loading of appropriate parameter values. 
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C. SETTING ATTRIBUTES 

1 • S to r ag e Seoul rgment^ 

When an attribute is set it does not necessarily 
have to taJce effect immediately. Tnerefore memory locations 
must be available to store tne values of attribute settings 
until an appropriate operation code using them is loaded 



opcode T flags 
0011 0101 ! 0000 0011 



0F1 

0000 0001 0000 0010 



color table index 
0000 0000 0000 0100 

~Iine~code word I 
0000 0001 0000 0001 



line code word 2 
0000 0000 0000 0011 



data length word 
] 0000 0000 0000 1000 



x start coordinate 
0000 0000 0110 0100 



y start coordinate 
0000 0000 0110 0100 



x end coordinate 
0000 0001 1111 0100 

y - end~coordInati~ 
0000 0001 mi 0100 



Figure 6. Instruction buffer for line with specified color 

and style 
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Into tne instruction buffer. Tne RM-9400 nas tne capacity 
for setting 22 different parameters, eacn one corresponding 
to a bit in one of tne operand flag words (16 in Oil and 6 
in 012). Not all of the parameters that are entered into the 
Ramtefc instruction are limited to a single word. Although 
some parameters do require only one word there are others 
that need 2 or 4, and in one case 12, words of storage. The 
total storage required for the 22 parameter settings is 47 
words. A Global, integer array of 47 elements named PARAM is 
set up as part of a BLOCS DATA program to store these values 
as they are set. Two additional "read only” arrays are also 
part of that BLOCK DATA subroutine. These aid in referencing 
the PARAM array. Integer array PRMPTR of length 22 contains 
indices to the starting location in PARAM where a particular 
parameter's values are saved. Each entry in PRMPTR 
corresponds to a flag in one of the operand flag words. 
Elements 1 through 16 of PRMPTR contain pointers to the data 
associated with bits 0 through 15 of OFl. Elements 17 
through 22 do the same for bits 0 through 5 of 0F2. The 
second array, PRMSIZ, is a parallel array to PRMPTR. Each of 
its integer values is the size, in words, of tne particular 
parameter pointed to by the corresponding element in PRMPTR. 
The values of PRMPTR and PRMSIZ are fixed at compile time 
and remain unchanged throughout the program. PARAM is 
initially set to all zero entries and gets updated as the 
various attribute values are assigned. 



74 



Tnere are also two logical arrays and tnree logical 
variables involved in keeping trade of attribute settings. 



Tbe elements of the logical arrays correspond to tne bits of 
OF1 and 0F2. They are named OF1ARR and 0F2ARR. If a bit in 
either OF1 or 0F2 is to be set by a particular subroutine 
call then the element in OF1ARR or 0F2ARR that corresponds 
will have a FORTRAN value of .TRUE.. The logical variables 
correspond to the lowest three bits of tne primary flag set 
of the Ramtelc instruction operation code word. For bit 2 
there is 0F2FL, for bit 1 there is OF1FL and for bit 0 there 
is DFFL. All of the logical variables, including the arrays 
are initialized to .FALSE.. 

Finally, the three words which actually control the 
instruction buffer size must be tept: 0F1, 0F2, and DLW 
(data length word). These are declared as integer variables 
in tne BLOCK DATA subroutine and initialized to zero. 



2 • 7 a_l ue S to rage Opera ti ons 

Vhen a subroutine that sets an attribute is called, 
several operations must taice place, not necessarily in any 
particular order. One of the required events is that the 
attribute values must be entered into the proper location in 
PARAM. This is done in a special subroutine called 04L0AD. 
Its essential part is a DO loop wnicn fills the array 
starting at the location indicated by an element of PRMPTR 
and filling the number of words indicated by the 
corresponding PRMSIZ value. Along with setting the parameter 
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values a flag marking the fact that they are to be used 
must also be set in either 0F1ARR or 0F2ARR. Also, tne flag 
indicating either OF1 or 0F2, must be set, so either OF1FL 
or 0F2FL becomes .TRUE.. 

Tne code for any subroutine that sets an attribute 
can be written according to the following algorithm: 

input: parameter values 

begin attribute setting subroutine 

set OF1FL or 0F2FL 

if flag in OF1ARR or 0F2ARR not set then 
set OF1ARR or 0F2ARR flag 

set flag in OF1 or 0F2 by adding proper power of 
two 

end if 

store parameter values in PARAM 

end 

Two subroutines nave been written that carry out this 
process. They are 04C0LR and 04BC0L. The source code for 
them is found under RSX on the PDP-11/50 in directory 
DP3:[301,lJ. The subroutine 04L0AD is also found in tnis 
directory. 

3 . Fil ling the Instructio n Buffer 

The critical subroutine in module 04LIB2 is COPCOD. 
This is the one that controls the filling of the 
instruction. It is invoiced by the primitive and control 
subroutines in 04LIB2. The routines that call COPCOD pass as 
a parameter an index to an array containing the Rarrtelc 
operation codes. These operation codes are set into the 
array OPCODE at compile time. They are designed to be the 
Ramtefr equivalent of the intended 7GM function. COPCOD gets 
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the 


actual code from 


the 


array OPCODE. 


The 


operation 


code 


and 


the 


primary flags 


are 


then combined 


into 


tne first 


word 


of 


the 


instruction buffe 


r. COPCOD also 


causes the operand 



flagwords (OF1 and 0F2), their parameter values and the data 



length word to be loaded If any of them are required. The 
text or numeric data is loaded by the primitive or control 
routine itself. 

The following algorithm shows the operation of 

COPCOD. The code can be found in directory DP3:[301,lJ: 

input: OPCODE index 
begin COPCOD 

get actual operation code from array OPCODE 
if 0F1FL = true then set flag bit 1 

if 0F2FL = true then set flag bit 2 

shift operation code to upper byte of first 
instruction word (multiply by 256) 

add flagword to shifted operation code 

load operation code word into buffer 
load 0F1 and/or 0F2 as indicated by flags 
load parameters in proper order from PABAM 
load data length word if necessary 

end 

As with attribute setting, all subroutines which are 

primitive functions can be patterned after a single 

algorithm. Control functions can follow tnis same pattern 

though they typically will not require data values to be 

placed in the instruction buffer. The algorithm is: 

input data values 
begin function execution 

set DFFL (data flag) if appropriate 
set bit 0 of flags 

set data lengtn word (DLW) to number of bytes of data 
call COPCOD — pass OPCODE index 
load data values 
execute instruction 

end 
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A number of routines nave been written following 
tnis aigorltnm. They include: 

04D0T place a point at specified coordinates 

04M0VE cnange current cursor position 

04DRAVT draw a line between two specified points 

04SSTR output a text string 

04RSET erase tne screen. 

All can be found in directory DP3 : [301 , 1] . It snould be 
noted that the routine 04STR, which builds an instruction 
for text output, inserts an extra step before loading the 
data. 04STR receives its text data in an integer array with 
one alphanumeric character per element. The Ramtelc requires 
textual data output to be formatted to one character per 
byte. Therefore 04STR must maice this conversion before 
loading the data into the buffer. 

4 . T es t in g 

As tne routines were developed tney were tested for 
operability. The testing was at a very low level simply 
checking that the instruction buffer was being properly 
constructed and transmitted to the Rli-9400. All of the 
routines developed in tnis portion of tne study nave been 
successfully checked in this manner. The test programs are 
modularized, each being called by a master routine called 
DUMTST. The individual test routines are named LINTST (LINe 
drawing TeST) , PTTST (PoinT placement TeST), TXTST (Text 
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output TeST) and COLTST (COLor selection TeST). Tneir source 
code can be found in directory DP3 : 1301 , lj . 

All of the routines developed were originally part 
of tne 01LIB2 module of tne Cnromatics driver. A copy of the 
original software is available in directory DP3:[5,3]. After 
modifying the names to conform with the selection of #4 as 
the identifier for the new device driver each subroutine was 
removed from the module and treated as a separate entity. 
This was done for ease of editing and troubleshooting. To 
support this process command files were created to 
facilitate repetitive compilation and tass building 
operations. The files C0liP.CMD and TC0MP.CMD in directory 
DP3:[301,1] cause the compilation of ail the driver software 
and all tne test software, respectively. File DUM.CMD builds 
the test taste DUMTST.TSK, by Uniting the modified 
subroutines, the BLOCK DATA programs and the test routines. 

Among tne test routines some short pieces of code 
have been included to accomodate testing. The important ones 
are RMINIT, which inserts the color table into the Ramteic 
refresh memory, and 3ICTKT, which causes text output to be 
printed in a larger than normal format for viewing ease. 
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APPEND I I C. PROGRAMMING WITH VGM 

Graphics programming using VGM is actually a nimbly 
specialized use of FORTRAN. Because of this, all tne rules 

of PDP-11 FORTRAN apply as well as those of the graphics 

system. When using VGM the programmer generates a main 
program which references a library of graphics subroutines. 

A. SETUP 

VGM is initialized by three essential statements. First 

CALL INIT 
( INITialize ) 

starts the VGM session. It sets the variables required by 

both the operating system and VGM itself. Tne routine 

ensures that each time VGM is invoiced it is in the same 

starting state. Immediately following this, 

CALL INISTR(n) 

(INItialize STReam) 

activates the device dependent driver software for stream 
'n'. It sets device parameters and uses the operating system 
process handling capabilities to allow application program 
access to the particular device or devices on the stream. 
Lastly, 

CALL SELSTR (nl ) 

(SELect STReam) 

directs all graphics output to stream 'nl'. If another CALL 
SELSTR (n2) instruction is encountered before a CALL 
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DELSTR(nl) instruction, tne grapnics output will go to both 
streams nl and n2. It is mandatory that each stream be 
prepared by a CALL INISTR(n) before it is selected by a CALL 
SELSTR (n). 

B. ENYIRONMENT SPECIFICATION 
1. The Coordinate System 

In VGM, the user defines his graphical world in 
arbitrarily selected "world coordinates". These coordinates 
are tne medium tnrougn wnicn ne communicates positional data 
to the system. 7G M processes those world coordinates through 
a series of viewing transformations and eventually derives 
"normalized device coordinates" (NDC). The NDC's are real 
values ranging from 0.0 to 1.0 and are mapped onto tne 
physical device selected for viewing. A picture in NDC is 
independent of any particular graphics device. 

For YGM to properly execute the string of required 
coordinate transformations, the Normalized Device Coordinate 
System must be specified before World Coordinates. With 

CALL NDCSPC (nstrm, width, height) 

(Normalized Device Coordinate Specification) 

a rectangular portion of the view surfaces of terminals on 
stream 'nstrm' is defined. 'Width' and 'height' are real 
numbers ranging from 0.0 to 1.0. They indicate the relative 
part of that dimension of the view surface that is to be 
used. One or the other must be 1.0. Therefore, either tne 
full screen width or the full screen height will be used. 
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The remaining dimension will be proportionately adjusted. A 
statement sucn as 

CALL NDCSPC (1,1.0, .75) 

will set up tne devices on stream #1 so that a viewing area 
using the full width of the screen is made available. The 
height will be 3/4 as large as the width if that much is 
available. If a dimension specification is too large, the 
maximum available is used. The NDCSPC command normally is 
used only once for each stream. 

2. The View Surface 

After setting the total viewing area available, 
"viewports” are assigned to the streams by 

CALL VIEW (nstrrn, xmin, ymln, xmax, ymax ) 

A viewport is a portion of the available surface (NDC space) 
that will be used, up to, but not exceeding, the total 
declared surface. 'Xmin', 'ymin', 'xmax', and 'ymax' are NDC 
values and must be within the bounds specified in the NDCSPC 
call. A viewport declaration stays in effect until a new one 
is declared. The viewport may be changed as often as the 
user desires in the main program. 

The "window" is the counterpart of the viewport in 
the world coordinate system and is set by 

CALL WINDOW (nstrrn, xmin, ymin, xmax, ymax) 

The parameter values except for 'nstrrn' are in World 
Coordinates and are arbitrarily selected by the user to meet 
his requirements for clipping and image transformations. 
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This is the part of World Coordinates that the picture is 
created in. The window is the wont area of the programmer. 
For display, the clipped and transformed images in the 
window are mapped to the NDC space defined by the viewport. 
3. Background Color 

On color capable devices the last environment 

setting operation is to define the background with 

CALI BCKCOL ( i va 1 ) 

(Background COLor) 

to set the attribute and 

CALL ERASE 



to bring it up on the screen. 

Tne current version of VGM 
of only eight colors available, 
specifying an integer value between 
default color table contains black, 
magenta, yellow, and white, in that 



allows selection of one 
Selection is done by 
0 and 7 for 'ival'. The 
blue, green, cyan, red, 
o rder . 



C. CREATING A PICTURE 

With the devices initialized, and the environment set, 

the next step is to open a segment. To do this the type of 

the intended segment must first be declared by 

CALL SEGTYP (itype) 

(SEGment TTPe ) . 

An 'itype' value of 1 indicates tnat all subsequently 
created segments will be non-retained. A value of 2 means 
tnat they will be retained. 



83 



After tne type nas been established, tne segment Is 
opened with 

CALL CRESEG (nsegmt) 

(CREate SEGment). 

'Nsegmt' is an integer value that uniquely identifies tne 
particular segment. Once tne segment is open, the user 
creates his image by invoking primitives and assigning 
attributes. Any primitive attribute values declared before 
closing the segment are static. Declaration of segment 
attributes is not allowed while a segment is open. As each 
primitive is eiecuted its contribution to the total image 
will be displayed. When tne particular image is completed, 
the 

CALL CLOSEG 
(CLOse SEGment) 

instruction is issued. It is not necessary to specifically 
identify tne segment being closed, since only one is allowed 
to be open at any given time. 

After closing a segment, a number of options are open to 
the user. He may terminate the session by normal FORTRAN 
procedures or ne may continue on and manipulate devices, 
streams and segments. He may alter dynamic attributes and 
create additional segments subject to tne limitations of VGM 
and FORTRAN. 

D. EXECUTING THE PROGRAM 

After creating the source code for a VGM program it 
should be independently compiled into an object file. 
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Incorporating the user file and the VGM library into an 
executable tast requires tne following command sequence to 
be issued to the RSX Taslc Builder (for purposes of the 
example, MAIN is selected to be the name of the user's 
program ) : 

TKB> MAI N/CP/FP , VGM/-SP=VGMLT /MP 
ASG = ST: 1 
ASG = ST: 2 
ASG = ST : 4 
ASG = TI: 5 
ACTFIL = 3 
MAXBUF = S0 
FMTBUF = 80 
// 

Before executing the tasK (now stored in file MAIN.TSK) it 
is necessary to INSTALL the device drivers. For each stream 
that will be used by MAIN.TSK. The MCR command to RSX is 

>INS OnDRIT 

where 'n' is the integer identifier for the particular 
driver. The command 

>RGN MAIN 

will execute the user's graphics program. 
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